[Instrumentor] A configurable instrumentation pass plugin #151551
Conversation
Both internally and externally we instrument code all the time. Usually, those are hand written traversals that look for some specific instructions or program points and then provide information to a runtime. Since the real difference is in the runtime, and the instrumentation is basically always the same, people can use this Instrumentor pass and configure it to their needs. Initial implementation only instruments alloca instructions but shows the setup, and configurability via a JSON file.
|
I guess we don't want another generic plugin like Bye? 👋 I integrated the Instrumentor pass from #119038 |
|
✅ With the latest revision this PR passed the C/C++ code formatter. |
| @@ -0,0 +1,341 @@ | |||
| //===-- Instrumentor.cpp - Highly configurable instrumentation pass -------===// | |||
There was a problem hiding this comment.
I like the instrumentor - but is there a user that needs this today? I wonder if this should be part of a test or example instead of a full tool. For what it's worth, I would like some code that uses the plugin API to be built by default.
There was a problem hiding this comment.
Yes, we need tool-like plugin to get test coverage for subprojects and packagers. I guess there are users, but I don't know for sure. It was presented on EuroLLVM with the idea to hardcode it as a default-disabled pass. I think it's a great fit for a plugin that lives upstream. @jdoerfert @kevinsala What do you think?
| static std::optional<std::string> getEnv(const std::string &Var) { | ||
| const char *Val = std::getenv(Var.c_str()); | ||
| if (!Val) | ||
| return std::nullopt; | ||
| return std::string(Val); | ||
| } |
There was a problem hiding this comment.
If we are already using command-line options elsewhere in the instrumentation pass, why not use them here instead of environment variables?
There was a problem hiding this comment.
For the moment, I was aiming for minimal changes on the Instrumentor, so I kept it as a leftover from my previous draft that used a generic plugin. They define in which part(s) of the pass pipeline we insert the pass. In contrast to the current command-line options this is not specific for the Instrumentor. I am happy to change it to whatever fits best.
|
Thank you for this! I would love to see a user of the plugin API built by default, both as extra assurance that the API maintained and to serve as documentation for plugin authors. I think this is valuable work. |
weliveindetail
left a comment
weliveindetail
left a comment
There was a problem hiding this comment.
Thanks for your feedback
| @@ -0,0 +1,341 @@ | |||
| //===-- Instrumentor.cpp - Highly configurable instrumentation pass -------===// | |||
There was a problem hiding this comment.
Yes, we need tool-like plugin to get test coverage for subprojects and packagers. I guess there are users, but I don't know for sure. It was presented on EuroLLVM with the idea to hardcode it as a default-disabled pass. I think it's a great fit for a plugin that lives upstream. @jdoerfert @kevinsala What do you think?
| static std::optional<std::string> getEnv(const std::string &Var) { | ||
| const char *Val = std::getenv(Var.c_str()); | ||
| if (!Val) | ||
| return std::nullopt; | ||
| return std::string(Val); | ||
| } |
There was a problem hiding this comment.
For the moment, I was aiming for minimal changes on the Instrumentor, so I kept it as a leftover from my previous draft that used a generic plugin. They define in which part(s) of the pass pipeline we insert the pass. In contrast to the current command-line options this is not specific for the Instrumentor. I am happy to change it to whatever fits best.
3 participants
Pass plugins are a commonly requested extension for LLVM-based tools. Better support for these extensions benefits the LLVM ecosystem and might slow down the growth of the monorepo. We currently lack test coverage for pass plugins, because we only have example plugins (and no reference), but most bots don't build examples. As a result we also can't test cross-project integration. Features like parsing of plugin parameters in Clang remain broken and get no attention.
This draft adds a reference plugin in LLVM that we can test in subprojects. For illustration, it comes with tests for plugin parameters and pipeline entry-points.